Hm, so @AndersonTorres is listed as maintainer for scons, but was not mentioned by ofborg. I assume that's because I only change the setup-hook.sh file and not a nix file.

Do I need to mention all maintainers manually in this case? I assumed ofborg would also work by commit prefix scons:, but that didn't add the mention either.

Rebased to resolve merge conflicts. Anyone up for a review of the first five stdenv: commits for the general base?

I did a full build and test of the stdenv and everything checks out. I think the printf suggestion can be a separate PR.

I raise the motion that we merge this PR.

We'll have to look out to ensure nobody else starts to depend on the stdout-based concatStringsSep in the meantime, but I think that's manageable:)

Really great to see this land! Looking forward to the follow‐up for the other hooks. Let’s all do our best to get structured attributes on by default as soon as we can.

Bisect says the bfd97a6 stdenv: make _accumFlagsArray independent of structuredAttrs changed quoting rules for some variables. For example sudo is now broken in staging as:

$ nix build --no-link -f. -L sudo
...
sudo> ./configure: interpreter directive changed from "#! /bin/sh" to "/nix/store/k5i08diz6c0bvklbzdp35rpprrnml9bh-bash-5.2p32/bin/sh"                               
sudo> configure flags: --disable-static --prefix=/nix/store/8kqimiqs90p0vlvm43ia2v46wc040gbw-sudo-1.9.15p5 --with-env-editor --with-editor=/run/current-system/sw/bin
/nano --with-rundir=/run/sudo --with-vardir=/var/db/sudo --with-logpath=/var/log/sudo.log --with-iologdir=/var/log/sudo-io --with-sendmail=/run/wrappers/bin/sendmail
 --enable-tmpfiles.d=no password for %p:                                                                                                                             
sudo> configure: WARNING: you should use --build, --host, --target                                                                                                   
sudo> configure: WARNING: you should use --build, --host, --target                                                                                                   
sudo> configure: WARNING: you should use --build, --host, --target                                                                                                   
sudo> configure: WARNING: invalid host type: %p:        
...
sudo> checking for password-ar... ar
sudo> checking for password-ranlib... ranlib
sudo> checking build system type... Invalid configuration 'password': machine 'password-unknown' not recognized
sudo> configure: error: /nix/store/k5i08diz6c0bvklbzdp35rpprrnml9bh-bash-5.2p32/bin/bash ./scripts/config.sub password failed

This happenens because sudo has this snippet:

  configureFlagsArray = [
    "--with-passprompt=[sudo] password for %p: " # intentional trailing space
  ];

It used to be passed as a single string, but now it gets expanded to an argument list.

I guess we just need to restore the special handling of *Array? I’ll try to take a look in the next day or so if nobody beats me to it.

It used to be passed as a single string, but now it gets expanded to an argument list.

Most peculiar, I'm surprised this used to work because this does not seem to be a __structuredAttrs derivation yet it sets *Array as a nix variable...

EDIT: it probably worked because *Array was used with "${...[@]}" unconditionally of it being an actual array, so maybe bash saw it as "a single element-array that wasn't declared as an array" or something - I'm not a bash expert, but I think we should simply enable __structuredAttrs:)

I guess just toggling on __structuredAttrs would be nice, but this is going to break out‐of‐tree packages. We probably need to fix it.

I guess just toggling on __structuredAttrs would be nice, but this is going to break out‐of‐tree packages. We probably need to fix it.

👍🏻 Two separate matters: make sudo structuredAttrs, add a warning/error out-of-tree users when [[ name = *"Array" ]], possibly recovering the old behavior

FWIW I think the way *Array variables are used in the manual is they are set on the bash side, e.g. in preConfigure

EDIT:

I’ll try to take a look in the next day or so if nobody beats me to it.

I'm probably free in a couple of hours

With #334973 merged, I think we're safe for staging-next. Anyone disagree?